Thank you for the PR.

What you did simply prevented validation on nested date fields completely. We still need validation.

The issue was that the wrong field handle was being exposed in the validation error. There was no nesting. So really, even if you didn't have a conflicting field, the validation would fail but you'd see no error message at all.

I pushed an update so the validation would run using a generic field name, then re-throw with the appropriate handle path (e.g. replicator.3.date). This was simpler than trying to massage the value to match the expected structure.

I see that this extra validation is a bit awkward in general, but this'll do for now. 😄

Thank you for the PR.

What you did simply prevented validation on nested date fields completely. We still need validation.

The issue was that the wrong field handle was being exposed in the validation error. There was no nesting. So really, even if you didn't have a conflicting field, the validation would fail but you'd see no error message at all.

I pushed an update so the validation would run using a generic field name, then re-throw with the appropriate handle path (e.g. replicator.3.date). This was simpler than trying to massage the value to match the expected structure.

I see that this extra validation is a bit awkward in general, but this'll do for now. 😄

Thanks for merging it!

When I prevented validation, it only applied to nested fields — but they still exposed the correct field handles for validation. So from my perspective, skipping validation inside the nested fields seemed fine, since the parent level already takes care of validating them, as long as the handles are correctly mapped.